-
Notifications
You must be signed in to change notification settings - Fork 819
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restrict rendering of natural=cape to nodes, change font to standard #3732
Conversation
As the person who originally did the PR for rendering capes, my opinion is that it might have been worth waiting until the discussion in #3634 was in a semi-complete state and it was agreed that this is an actual solution. As it is, the agreements put forth in #3634 that support this PR are rather weak, originally only put forward by a few people (or really one person), and I don't see much support of them. It might a solution after the discussion is concluded though. Also, there was a reason why capes were rendered like islands in the original issue/PR. I don't remember what the reason was, but maybe you should read it over and state why rendering them that way is problematic in the PR message. |
I appreciate the work you did in the original PR to get these rendered in #3452 - especially all the tests you did to confirm that z14 was the right zoom level to show capes. That was a lot of work, thank! Unfortunately, I missed the commit that changed the PR to include capes mapped as areas. I was under the misimpression that the plan was to only render nodes, so I didn't say anything at the time.
I read through all of the discussion in #3452 prior to making this PR, and it was not clear why the maintainer requested that they be rendered like islands. The wiki description and taginfo at the time were clear that nodes were used for over 98% of capes (as is the case now). I can only speculate that perhaps there was some confusion between cape and peninsula? However, now that natural=peninsula is an approved feature, this is the correct way to map an area of land that is mostly surrounded by water. See: https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcape and https://wiki.openstreetmap.org/wiki/Tag:natural%3Dpeninsula: "The tag natural=cape refers to a coastal extreme point, that is the tip of a land area that projects into water. In contrast, natural=peninsula refers to a land area that projects into water and that is nearly surrounded by water." This was clear during the proposal process for natural=peninsula and when it was discussed on the tagging list: https://wiki.openstreetmap.org/w/index.php?oldid=1813152 includes the text above. So natural=cape on a natural=peninsula is like a natural=peak on a mountain range or ridge; it's a point on a larger feature. |
That explains it. I seem to remember you being involved in another natural feature being rendered at that time. So I was wondering why you didn't speak up about it back then. I don't have a problem with removing area rendering per say, but I don't see how point rendering would necessarily be anymore accurate. Since it's impossible to really tell where the center of a cape is. As apposed to something like peaks that have clear end points at the top. So, it doesn't really solve the problem @imagico has with improper mapping. Which is why I why I think he wants it reverted completely. Ultimately, I think there's really only two options here. 1. accept that some things will be arbitrarily sometimes due to their "fuzzyness," but its still worth it for name rendering 2. Remove any none ground verifiable things from rendering. Including retail/residential/etc landuse and leisure=park. Otherwise, if rendering is removed just for these tags, it will be majorly slanted and not actually deal with the underlining problems of encouraging mapping things that aren't verifiable. Personally, id love to see residential/retail/commercial landuse not be rendered. All of them are pretty much worthless due to people mapping them wrong to make the map look pretty. It usually comes at the cost of mapping other more important things also. If there's going to be a stand about this though, it should apply outside of just the natural=* domain. That's just my opinion. Btw, I don't have anything against the rendering color being changed either. I seem to remember that I was actually against them being rendered like islands myself, but I went with that color because its @kocio-pl and others wanted. I'm just interested as to why its suddenly problem now or needs to be changed. I don't think there's anything inherently wrong with rendering them like islands, even if I didn't agree with it at the time. They are both water related land masses. |
Note while i would have added rendering of natural=cape for nodes only - based on mostly the same reasons you provided - i have not specifically objected to the idea of rendering polygon features tagged natural=cape. I just objected to taking the polygon way_area into account for rendering decisions. I think it is unnecessary to render polygons tagged natural=cape because of the low volume of use and it would support mappers in consistent mapping not doing so. But i think it is important not to distract from the important part of not making rendering decisions based on way_area with the minor matter of nodes only vs. nodes or polygons. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested and seems to work fine.
Hm, I don't really understand why. For me it's quite natural and efficient tool to give the impression of the size of the object (and it works also in practice in this style). Could you explain it a bit? (This is just a general question, which is important to me while designing this style, not something related to this change in particular.) |
I explained this on many occasions - way_area is derived from the polygon geometry. If you use that for making rendering decisions without giving visual feedback in the map on the geometry you create an incentive to draw non-verifiable abstract geometries as a method to manually specify the way_area producing the subjectively desired rendering result. In this specific case i don't even think a cape has a specifiable, let alone verifiable size. I couldn't specify such for any of the following major capes even if i wanted to: https://www.openstreetmap.org/node/32532727 |
I see, so it's not really way_area problem. I would however ask how can one verify position of these 4 nodes for example? To make a problem simpler for a start - why Kap Morris Jesup is on the coastline and three others are not? |
I believe capes should be mapped at the extreme point of land, which would be the node on the coastline where it extends farthest into the body of water. This is the same idea with mountain peaks; you map the highest point. However, it doesn't make a large difference if the node is not exactly on the coastline. Similarly, many peaks are not exactly on the highest point of the mountain, but database users can make minor adjustments if needed when processing peaks. |
Now that natural=peninsula is an approved feature, this is the better way to map an area of land that is mostly surrounded by water. Many of the features that are currently mapped as a closed way or multipolygon and tagged with natural=cape can be retagged to natural=peninsula "The tag natural=cape refers to a coastal extreme point, that is the tip of a land area that projects into water. In contrast, natural=peninsula refers to a land area that projects into water and that is nearly surrounded by water." |
Cabo da Roca - westmost point of continental Europe Node location relative to the coastline is not really that meaningful since the cape and the coastline are not necessarily mapped together and the coastline in neither of these cases is particularly accurate (South Africa coastline in particular is largely imported and systematically off) Also people will often locate the cape not at the high water mark on the beach or scree at the shoreline but at the out-most part of the cliff or other prominent feature - like in case of Cabo da Roca. Apart from peaks and saddles capes are probably among the most easily and most precisely localizable physical geography features we have. |
If I understand you right, the location of capes is fuzzy (correct me if you didn't mind it). But still I see no answer for my question - how can one verify cape node location? The answer was where they are, but this exactly is a claim, and I look for verification of that claim. What source did you use for this claim? I guess only in the case of Cape Agulhas there is an artwork that - if it contains inscription with this name - can be taken as the location of a node. But what about others? |
Trying to address the question in a compact form to not too much venture outside the scope here - this is largely a discussion on verifiability in general. You need to distinguish between the verifiability of names and the verifiability of coordinates. Using one of the examples given - verifying the location of the westmost point of continental Europe is one thing, verifying that it is called the Cabo da Roca and verifying that it is this point that is called this way and not a different one is another one. Both of these work essentially like most other physical geography features - like for example a natural=peak. Determining coordinates of anything is always subject to variance of different independent determinations - sometimes more, sometimes less, depending on the situation and the type of feature. Determining the name can work either through physical manifestations like signs (which don't necessarily have to be directly at location obviously but can have the form of something like a guidepost some distance away) or through evaluation of local knowledge of people (which is tricky and more work intensive, especially if you are not a local yourself). |
Partial fix for #3634
Changes proposed in this pull request:
Explanation:
Test rendering with links to the example places:
Kolkas rags, Latvia - mapped as node
https://www.openstreetmap.org/#map=14/57.7488/22.6323
z14 Current
z14 After
Castle Neck - mapped as a closed way
https://www.openstreetmap.org/#map=15/42.6744/-70.7476
z15 Current
z15 After